1. Field of the Invention
This invention relates to videoconferencing. More particularly, it relates to the use of a wireless personal-area network and one or more cellular telephone systems to extend the audio and/or video portions of a conventional, landline videoconference.
2. Description of the Related Art
In response to the increasing complexity of connecting various electronic devices together, various wireless solutions have been proposed. In addition to cellular telephone standards such as GSM, CDMA, and TDMA, a system known as Cellular Digital Packet Data (CDPD) can be used to transmit data over analog cellular networks and Internet access over existing GSM networks can be accomplished with General Packet Radio Service (GPRS).
IEEE Standard 802.11b, commonly known as Wi-Fi, is used principally by systems which provide wireless Internet access up to about 150 feet indoors for laptop computers, Personal Digital Assistants (PDAs), cell phones and the like. Wi-Fi systems operate on a frequency of 2.4 GHz and data transfer speeds up to about 54 Mbps can be achieved.
A wireless technology known as Bluetooth has been proposed by a consortium of companies which include Ericsson, Nokia, Toshiba, Intel and IBM. Over 2000 companies have joined the Bluetooth Special Interest Group (SIG) and Bluetooth-enabled devices are beginning to appear in the marketplace. Bluetooth also operates in the unlicensed Industrial, Scientific & Medical (ISM) band at a nominal 2.4 GHz and achieves a range of about 10 meters using a 1 milliwatt transmitter. Data transfer speeds of about 720 Kbps are typical for Bluetooth wireless connections.
Bluetooth is a radio technology developed to deliver short-range wireless mobility. Bluetooth eliminates cables/wires/cords between devices, such as mobile phones and headsets, and provides services when devices are in close proximity to one another. Bluetooth facilitates fast, secure transmissions of both voice and data, even when the devices are not in line-of-sight.
More specifically, Bluetooth is a standard and a specification for small form-factor, low-cost, short range radio links between mobile PCs, mobile phones and other portable devices. Bluetooth devices can function in two modes—circuit switched and packet switched. Circuit switched mode is the most common mode for voice communications while packet switched is usually preferred for Internet data and higher bandwidth mobile communication systems.
A Bluetooth Personal Area Network (PAN or “piconet”) has a master and up to seven slaves thereby permitting the interconnection of up to eight devices in a radius of 10 meters. In a process known as Device Discovery, the master seeks devices by broadcasting requests; those slaves which are in a “discoverable” state answer with their identification numbers. A data channel is divided into time slots 625 microseconds long. The master transmits in even time slots, slaves in odd time slots. Packets can be up to five time slots wide. Data in a packet can be up to 2745 bits in length. Currently two types of data transfer between devices are defined: SCO (synchronous connection oriented) and ACL (asynchronous connectionless). In a Bluetooth piconet, there can be up to three SCO links of 64,000 bits per second each. To avoid timing and collision problems, the SCO links use reserved slots set up by the master. Masters can support up to three SCO links with one, two or three slaves. Slots not reserved for SCO links can be used for ACL links. One master and slave can have a single ACL link. ACL is either point-to-point (master to one slave) or broadcast to all the slaves. ACL slaves can only transmit when requested by the master. Data encryption is available for those users and applications that require additional security.
Up to ten Bluetooth piconets can overlap to form a “scatternet” which can link up to 80 Bluetooth devices (79 transmission channels are employed by the Bluetooth protocol, a limit based on the frequency used.) Unlike conventional radio operator networks, a Bluetooth piconet does not require an access point and, unlike infrared communication (e.g., per the IRDA standard), Bluetooth does not require a line-of-sight connection.
Bluetooth profiles are published definitions of implementations of Bluetooth wireless technology for particular uses. Profiles are the “services” offered by a device. In order for two Bluetooth-enabled devices to interoperate to complete a user task, both devices must implement a common profile.
Bluetooth radio transmitters utilize a spread spectrum, frequency hopping, signal at up to 1600 hops per second. The signal hops among 79 frequencies at 1 MHz intervals to provide a high degree of interference immunity. Compared with other systems in the same frequency band, the Bluetooth radio hops faster and uses shorter packets. The frequency range in the United States is 2400 MHz to 2483.5 MHz. In some other countries, the frequency range is more restricted and only 23 1-MHz channels are available. In both systems a guard band is used at the lower and upper band edge. Ten different types of hopping sequences are defined—five for the 79-hop system and 5 for the 23-hop system. The individual hopping sequences include the page sequence and the page response sequence which are used in the page procedure.
The signal transmitted by the Bluetooth link may be either half-duplex or full-duplex. Full duplex links in a Bluetooth piconet can send data at more than 64 Kbps—a speed sufficient to accommodate several voice channels. A half-duplex link can be established with a data rate of 721 kilobits per second in one direction and 57.6 Kbps in the other. If a half-duplex link having the same speed in both directions is required, a link with 432.6 Kbps in each direction can be made.
Unlike many other wireless standards, the Bluetooth wireless specification includes both link layer and application layer definitions for product developers which supports data, voice and content-centric applications.
The Bluetooth protocol architecture is described in the Bluetooth specification (which is incorporated herein by reference). The Bluetooth specification may be described as a protocol stack with the Bluetooth Radio layer as its base. The radio layer defines the requirements for a Bluetooth transceiver operating in the 2.4 GHz ISM band. A transceiver that takes part in a power-controlled link must be able to measure its own receiver signal strength and determine if the transmitter on the other side of the link should increase or decrease its output power level. A receiver Signal Strength Indicator (RSSI) makes this possible. The instructions to alter the transmitter power are carried in the LMP link.
Above the radio layer in the Bluetooth stack is the Baseband layer which describes the specification of the Bluetooth Link Controller (LC) which carries out the baseband protocols and other low-level link routines. The Baseband is the physical layer of the Bluetooth stack. It manages physical channels and links apart from other services like error correction, data whitening, hop selection and Bluetooth security. The baseband protocol is implemented as a Link Controller which works with the link manager for carrying out link level routines like link connection and power control. The baseband also manages asynchronous and synchronous links, handles packets and does paging and inquiry to access and inquire Bluetooth devices in the area. The baseband transceiver applies a time-division duplex (TDD) scheme (alternate transmit and receive). Therefore, apart from the different hopping frequency (frequency division), the time is also slotted.
Thirteen different packet types are defined for the baseband layer of the Bluetooth system. Each packet consists of three entities: the access code (68/72 bits), the header (54 bits), and the payload (0-2745 bits). Access codes are used for timing synchronization, offset compensation, paging and inquiry. The header contains information for packet acknowledgement, packet numbering for out-of-order packet reordering, flow control, slave address and error check for header. The packet payload can contain voice field, data field or both. If it has a data field, the payload will also contain a payload header.
A Bluetooth controller operates in two major states: Standby and Connection. There are seven sub-states which are used to add slaves or make connections in the piconet. These are page, page scan, inquiry, inquiry scan, master response, slave response and inquiry response.
The Standby state is the default low power state in the Bluetooth unit. Only the native clock is running and there is no interaction with other devices. In the Connection state, the master and slave can exchange packets, using the channel (master) access code and the master Bluetooth clock.
The Link Manager carries out link setup, authentication, link configuration and other protocols. It discovers other remote Link Managers and communicates with them via the Link Manager Protocol (LMP). To perform its service provider role, the Link Manager uses the services of the underlying Link Controller (LC).
The Link Manager Protocol essentially consists of a number of PDU (protocol Data Units), which are sent from one device to another, determined by the AM_ADDR in the packet header. Link Manager PDUs are always sent as single-slot packets and the payload header is therefore one byte.
When a connection has been established between two Bluetooth devices, the connection consists of an ACL link. One or more SCO links can then be established.
Each Bluetooth link has a timer that is used for link supervision. This timer is used to detect link loss caused by devices moving out of range, the power-down of a device, or other similar failure. An LMP procedure is used to set the value of the supervision timeout.
The Host Controller Interface (HCI) provides a command interface to the Baseband Link Controller and Link Manager and access to hardware status and control registers. It provides a uniform command method of accessing the Bluetooth baseband capabilities. The HCI Link commands provide the host with the ability to control the link layer connections to other Bluetooth devices. These commands allow the Link Manager to exchange LMP commands with remote Bluetooth devices.
The Logical Link Control and Adaptation Protocol (L2CAP) is above the Baseband Protocol in the Bluetooth stack and resides in the data link layer. It supports higher level protocol multiplexing, packet segmentation and reassembly, and the conveying of quality of service information. L2CAP permits higher level protocols and applications to transmit and receive L2CAP data packets up to 64 kilobytes in length. Both Synchronous Connection-Oriented (SCO) links and Asynchronous Connection-Less (ACL) links are supported. L2CAP is packet-based, but follows a communication model based on channels. A channel represents a data flow between L2CAP entities in remote devices. Channels may be connection-oriented or connectionless. L2CAP relies on the flow control mechanism provided by the Link Manager layer in the baseband.
The RFCOMM protocol provides emulation of RS-232 serial ports over the L2CAP protocol. Two device types exist that RFCOMM must accommodate: Type 1 devices (communication end points such as computer and printers); and, Type 2 devices (devices that are part of the communication segment such as modems). On Type 1 devices, some port drivers must provide flow control services as specified by the API they are emulation. For example, an application may request a particular flow control mechanism such as XON/XOFF or RTS/CTS and expect the port driver to handle the flow control. On Type 2 devices, the port driver may need to perform flow control on the non-RFCOMM part of the communication path—the physical RS-232 port.
The Service Discovery Protocol (SDP) provides a means for applications to discover which services are provided by or available through a Bluetooth device. It also allows applications to determine the characteristics of those available services. A specific Service Discovery protocol is required in the Bluetooth environment inasmuch as the set of services that are available changes dynamically based on the RF proximity of Bluetooth-enabled devices which may be in motion. SDP uses a request/response model wherein each transaction consists of one request protocol data unit (PDU) and one response PDU. Every SDP PDU consists of a PDU header followed by PDU-specific parameters. The header contains three fields: a PDU ID which identifies the type of PDU; a TransactionID field which uniquely identifies request PDU's thereby permitting the matching of response PDU's to request PDU's; and, a ParameterLength field that specifies the length (in bytes) of all parameters contained in the PDU.
SDP allows Bluetooth-enabled devices to discover what other Bluetooth-enabled devices have to offer in the way of services. The process of looking for any offered services is termed “browsing”; “searching” means looking for a specific service. In SDP, the mechanism for browsing for services is based on an attribute shared by all services classes called the BrowseGroupList attribute. The value of this attribute contains a list of Universally Unique Identifiers (UUID's). Each UUID represents a browse group with which a service may be associated for the purpose of browsing.